preserve span when evaluating mir::ConstOperand

This lets us show to the user where they were using the faulty const (which can be quite relevant when generics are involved).

I wonder if we should change "erroneous constant encountered" to something like "the above error was encountered while evaluating this constant" or so, to make this more similar to what the collector emits when showing a "backtrace" of where things get monomorphized? It seems a bit strange to rely on the order of emitted diagnostics for that but it seems the collector already [does that](https://github.com/rust-lang/rust/blob/da8a8c9223722e17cc0173ce9490076b4a6d263d/compiler/rustc_monomorphize/src/collector.rs#L472-L475).

…iaskrgr

Rollup of 10 pull requests

Successful merges:

 - rust-lang#119029 (Avoid closing invalid handles)
 - rust-lang#122238 (Document some builtin impls in the next solver)
 - rust-lang#122247 (rustdoc-search: depth limit `T<U>` -> `U` unboxing)
 - rust-lang#122287 (add test ensuring simd codegen checks don't run when a static assertion failed)
 - rust-lang#122368 (chore: remove repetitive words)
 - rust-lang#122397 (Various cleanups around the const eval query providers)
 - rust-lang#122406 (Fix WF for `AsyncFnKindHelper` in new trait solver)
 - rust-lang#122477 (Change some attribute to only_local)
 - rust-lang#122482 (Ungate the `UNKNOWN_OR_MALFORMED_DIAGNOSTIC_ATTRIBUTES` lint)
 - rust-lang#122490 (Update build instructions for OpenHarmony)

Failed merges:

 - rust-lang#122471 (preserve span when evaluating mir::ConstOperand)

r? `@ghost`
`@rustbot` modify labels: rollup

preserve span when evaluating mir::ConstOperand

This lets us show to the user where they were using the faulty const (which can be quite relevant when generics are involved).

I wonder if we should change "erroneous constant encountered" to something like "the above error was encountered while evaluating this constant" or so, to make this more similar to what the collector emits when showing a "backtrace" of where things get monomorphized? It seems a bit strange to rely on the order of emitted diagnostics for that but it seems the collector already [does that](https://github.com/rust-lang/rust/blob/da8a8c9223722e17cc0173ce9490076b4a6d263d/compiler/rustc_monomorphize/src/collector.rs#L472-L475).

…iaskrgr

Rollup of 5 pull requests

Successful merges:

 - rust-lang#121885 (Move generic `NonZero` `rustc_layout_scalar_valid_range_start` attribute to inner type.)
 - rust-lang#122471 (preserve span when evaluating mir::ConstOperand)
 - rust-lang#122515 (Pass the correct DefId when suggesting writing the aliased Self type out)
 - rust-lang#122523 (Ensure RPITITs are created before def-id freezing)
 - rust-lang#122527 (Clean up AstConv)

r? `@ghost`
`@rustbot` modify labels: rollup

…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#121207 (Add `-Z external-clangrt`)
 - rust-lang#122174 (diagnostics: suggest `Clone` bounds when noop `clone()`)
 - rust-lang#122471 (preserve span when evaluating mir::ConstOperand)
 - rust-lang#122515 (Pass the correct DefId when suggesting writing the aliased Self type out)
 - rust-lang#122523 (Ensure RPITITs are created before def-id freezing)
 - rust-lang#122526 (Docs for `thir::ExprKind::Use` and `thir::ExprKind::Let`)
 - rust-lang#122527 (Clean up AstConv)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of rust-lang#122471 - RalfJung:const-eval-span, r=oli-obk

preserve span when evaluating mir::ConstOperand

This lets us show to the user where they were using the faulty const (which can be quite relevant when generics are involved).

I wonder if we should change "erroneous constant encountered" to something like "the above error was encountered while evaluating this constant" or so, to make this more similar to what the collector emits when showing a "backtrace" of where things get monomorphized? It seems a bit strange to rely on the order of emitted diagnostics for that but it seems the collector already [does that](https://github.com/rust-lang/rust/blob/da8a8c9223722e17cc0173ce9490076b4a6d263d/compiler/rustc_monomorphize/src/collector.rs#L472-L475).

…RalfJung

Avoid various uses of `Option<Span>` in favor of using `DUMMY_SP` in the few cases that used `None`

based on rust-lang#122471

`DUMMY_SP` is already the sentinel value we have that says "no span". We don't need to wrap these `Span`s in a separate `Option`.

…RalfJung

Avoid various uses of `Option<Span>` in favor of using `DUMMY_SP` in the few cases that used `None`

based on rust-lang#122471

`DUMMY_SP` is already the sentinel value we have that says "no span". We don't need to wrap these `Span`s in a separate `Option`.

Rollup merge of rust-lang#122480 - oli-obk:const-eval-span-no-opt, r=RalfJung

Avoid various uses of `Option<Span>` in favor of using `DUMMY_SP` in the few cases that used `None`

based on rust-lang#122471

`DUMMY_SP` is already the sentinel value we have that says "no span". We don't need to wrap these `Span`s in a separate `Option`.